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DETAILED ACTION 

1 . This application has been examined. 

2. Claims 1-20 have been examined and rejected. 

3. This is a resend of the Detailed Action sent out by the Office 7/29/04. The original Detailed 
Action was returned to the Office as "Undeliverable". 

Priority 

4. Receipt is acknowledged of papers submitted under 35 U.S.C. 1 19(a)-(d), which papers have 
been placed of record in the file, specifically, German Patent Application Number 100 01 484.4, filed 
1/15/00. 

Specification 

5. The disclosure is objected to because of the following informalities. Appropriate correction is 
required. 

6. The explanation of Figure 1, elements 6 and 7 are unclear as to whether each element individually 
contains a sensor and actuator model or weather element 6 contains a sensor model and element 7 
contains an actuator model. Specifically, Page 9, line 36-Page 10, line 5 specify "sensor model 6" or an 
"actuator model 6,7" followed by "sensor/actuator models 6 and/or 7". 

7. Page 10, line 29 and Page 12, line25, the spelling of "analogue" should be changed to "analog" 
for consistency with "analog/digital" as used throughout the specification. 

8. Page 13, line 36-Page 14, line 1, "signal generator" should be associated with element 41 in 
Figure 3 and "temperature cell" should be associated with element 40 in Figure 3. 

Claim Interpretation 

9. Claim 12 states "a subordinate regulating loop" and "fast regulation". It is unclear from the 
claims and the specification what a subordinate regulating loop and fast regulation are. This claim was 
interpreted to be directed to a feedback loop between the tested component and the drive model to provide 
variables to the drive model which in turn, create signals that drive the output stages of the signal 
interfaces. 
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10. The following is a quotation of the second paragraph of 35 U.S.C. 1 12: 

The specification shall conclude with one or more claims particularly pointing out and distinctly 
claiming the subject matter which the applicant regards as his invention. 

1 1 . Claim 12 is rejected under 35 U.S.C. 1 12, second paragraph, as being indefinite for failing to 
particularly point out and distinctly claim the subject matter which applicant regards as the invention. The 
claim states "a subordinate regulating loop" and "fast regulation". It is unclear from the claims and the 
specification what a subordinate regulating loop and fast regulation are, making the claim vague and 
indefinite. 

Claim Rejections - 35 USC § 102 

12. The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis 
for the rejections under this section made in this Office action: 

A person shall be entitled to a patent unless - 

(b) the invention was patented or described in a printed publication in this or a foreign country or 
in public use or on sale in this country, more than one year prior to the date of application for 
patent in the United States. 

13. Claims 1-20 are rejected under 35 U.S.C. 102(b) as being anticipated by Wagner et al (Wagner et 
al, "A Strategy to Verify Chassis Controller Software-Dynamics, Hardware and Automation", IEEE 
Transactions on Systems, Man, and Cybemetics-Part A: Systems and Humans, Vol. 27, No.4, July 1997), 
herein referred to as Wagner. 

14. As to Claims 1 and 2, Wagner teaches an apparatus for simulating an electrical sensor/actuator 
component comprising: a drive module including a model of the sensor/actuator component (page 481, 
column 2, lines 5-9), said drive module generating interface signals in accordance with signals of said 
sensor/actuator component (page 487, section HI, lines 14-17), said drive module further including at 
least one signal interface (Figure 5, "Hardware Interfaces"), wherein at least one signal interface 
generates, for each said interface connection pin, one of said interface signals corresponding to the 
electrical signals of the said sensor/actuator component (page 488, column 1, section A, paragraph 1, 
lines 7-10), wherein each of said at least one signal interface includes a control/regulation circuit (page 
488, column 1, section A, second paragraph, lines 3-7), wherein said apparatus includes modular 
construction in order to provide a separate signal interface for each interface component (Figure 5, 
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"Hardware Interfaces" show a modular design including Powertrain Simulation, Antilock Brake and 
Motor Load which are all separate signal interfaces). 

15. As to Claims 3 and 13, Wagner teaches the drive model further includes means for calculating 
mathematical modules for driving at least one signal interface and wherein said module generates real- 
time signals in order to obtain said interface signals in accordance with the simulated sensor/actuator 
components at the interface connection pins (Page 487, section HI, lines 9-17 and Figure 5, 
^^Simulation Computer"). 

16. As to Claims 4 and 14, it is concluded that since components in a design must be mounted on a 
printed circuit board, the controller as shown in Wagner Figure 5, being an actual hardware component, 
must be mounted on a printed circuit board. Further, it is concluded that a design on a printed circuit 
board will include interface connections to any system that is needed to realize the design, allowing 
connection to the interface pins in the component that will be receiving or transmitting signals to the 
system. 

1 7. As to Claims 5,6,15, and 16, Wagner teaches signal interface has an output stage that can 
function to output power or receive power. Figure 5 shows the signal interfaces providing two-way 
communication between the simulated models and the controller. Further, page 488, column 1, section 
A, lines 3-10 state that the PSI and ABI signal interfaces perform signal conditioning which is applied to 
outputs from the controller or from the RTS, signifying that this interface functions to output power (from 
the RTS) or receive power (from the controller). 

18. As to Claims 7 and 17, Wagner teaches said drive model comprising a computer for providing 
an equivalent circuit of the sensor/actuator component as said model (page 481, column 2, lines 3-9). 

19. As to Claims 8 and 18, Wagner teaches said model is adapted to signals required at an interface 
connection pin by utilizing specific parameters (page 488, column 2, second paragraph, lines 11-14) as 
an example, wherein the commanded motor current is measured by the interface unit and supplied as 
input to the motor driver model executing in the simulation computer. 

20. As to Claims 9 and 19, Wagner teaches a fault simulation module for generating one of a line 
interruption and a short circuit (Figure 5, "Failure Module" and page 488, column 2, last paragraph). 

21 . As to Claims 10 and 20, Wagner teaches each signal interface has a regulating circuit for 
adjusting one of voltage and current to a value specified by said model (page 488, column 1, section A, 
paragraph 1, section A, paragraph 2, lines 3-14). 
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22. As to Claim 11 and 12, Wagner teaches the regulating circuit includes a feedback arrangement 
to the drive module in order to provide actual values of regulated variables to said model (page 488, lines 
11-20). 

Conclusion 

23. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. 

24. Raman et al (Raman et al, "Design and Implementation of HIL Simulators for Powertrain Control 
System Software Development". Proceedings of the American Control Conference, June 1999, pages 
709-713) teach a hardware-in-the-loop simulation system including actuator and sensor models. 

25. Any inquiry concerning this communication or earlier communications from the examiner should 
be directed to Mary C. Hogan whose telephone number is 703-305-7838. The examiner can normally be 
reached on 7:30AM-5PM Monday-Friday. If attempts to reach the examiner by telephone are 
unsuccessful, the examiner's supervisor, Kevin Teska can be reached on 703-305-9704. The fax phone 
number for the organization where this application or proceeding is assigned is 703-872-9306. 
Information regarding the status of an application may be obtained from the Patent Application 
Information Retrieval (PAIR) system. Status information for published applications may be obtained 
from either Private PAIR or Public PAIR. Status information for unpublished applications is available 
through Private PAIR only. For more information about the PAIR system, see http://pair- 
direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic 
Business Center (EBC) at 866-217-9197 (toll-free). 

Mary C Hogan 
Examiner 
Art Unit 2123 
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A Strategy to Verify Chassis Controller 
Software — ^Dynamics, Hardware, and Automation 

John R. Wagner and John F. Keane» Member, IEEE 


Abstract— A reaMiine hardware-iD-tfae-loop tool set is pre- 
sented to test automotive chassis controllers. The use of high- 
speed compoters, specialized hardware interfaces* and Instmroeo- 
tation, as weU as simulation OKKtels and automation software, 
provide a realistic and rcpeatable laboratory environment to 
supplement in-vefascle testing. In this paper* the dynamics for a 
variety of chassis modeb are presented to support the verification 
of integrated controller hardware and software. To implement 
these mathematical descriptions the computer hardware, labo> 
ratory equipment, and simulation sofhvare are discussed. The 
automated testing features of the simulator permit the creation 
of script files and test suites for regression testing and reuse 
on similar programs. A number of issues such as simulator 
requirement, hardware interfaces, and the need for metrics are 
explored in order to facilitate the development and justification 
of a simulation capability. 


NOMENCLATURE 


a 

Distance from GG to front axle, (m). 


Vertical pressure center long, offset, (m). 

Ai 

Cross sectional area, (m^). 

AT 

Wheel aligning torque, (N*m). 

AT 

Aligning torque, ({N*m}/rad). 

b 

Distance from CG to rear axle, (m). 

c 

Half of front wheel track, (m). 

Ca 

Lateral tire stiffness, (N/rad). 

Co/ > Car 

Front, rear total cornering stiffness, (N/rad). 

Ca 

Aerodynamic drag coefRcient 


Wheel damping coefficient, 


({N»m}/{nKlAi}). 

CG 

Center of gravity. 

d 

Half of rear wheel track, (m). 


Suspension pitch damping, (N/{m*rad/5}]. 


Shock absorber roll damping, 


(N/{m^rad/s}). 

D 

Rolling tire resistance, (N)* 


Rolling resistance, (N). 

€ 

x-distance from king pin to wheel CG, (m). 

f 

y-distance from king pin to wheel CG, (m). 


Suspension Coulomb damping force, (N). 


Aerodynamic drag force, (N). 

^ iamp 

Suspension viscous damping force. (N). 


Suspension force, (N). 

^ spring 

Suspension spring force, (N). 


Manuscrqu received May 2S. 1995; revised April 14. 1996 and June 14. 
1996. 

The authors are with the Systems Technology Dcpartmcm> Deico 
Electronics Cofporation, Kokonx>, IN 46904-9005 ISA (e-mail: jrwag- 
Dci@cngjlelcodcctcom). 

Publisher Item Identifier S 1083-4427(97)03475-9. 


Fxn, Longiuidinal tire force in wheel plane, (N). 

2^ Tire force along forward body axis, (N). 

Lateral tire force in wheel plane, (N)- 
Fy Tire force along lateral body axis, (N)- 

F, Normal tire load, (N). 

AF, Vertical load transfer, (N). 

£Fx Sum of longitudinal forces, (N)- 

EFy Sum of lateral forces, (N). 

g Acceleration constant, (m/s^). 

h Center of gravity height, (m). 

W Distance from wheel center to ground, (m). 

ha OistaiYce from CG to aerodynamic force, (m). 

^5 Height of sprung mass CG above roll axis, 

(m). 

ia>So Actual and estimated motor current, (amps) 

x^Jl^ Commanded and measured motor current, 

(amps). 

*c^»i Serial value of commanded motor current 

/tpy Wheel inertia about spin axis, (kg*m^). 

Sprung mass inertia about roll axis, (kg*m^). 

Vehicle inertia about x and z axes, (kg*m^). 
/yy Vehicle inertia about pitch axis, (kg^m^). 

Vehicle inertia about yaw axis, (kg*m^). 
k0 Suspension roll stiffness, ({N*m}/rad). 

Suspension pitch stiffness, (N/{m*rad}). 
m Total vehicle mass, (kg). 

Sprung mass, (kg). 
£Mx Sum of moments about roll axis, (N*m). 

SMy Sum of moments about pitch axis, (N*m). 

EAf, Sum of moments about yaw axis, (N*m). 

R Undefiected tire radius, (m). 

Re Effective radius, (m). 

5x Longitudinal wheel slip. 

t Time, (s). 

t« Distance between vehicle longitudinal center 

line and shock absorber, (m). 

% Wheel brake torque, (N*m). 

Td Wheel driveline torque, (N*m). 

u,tij Longitudinal vehicle, wheel center speed, 

{mis). 

Wheel center speed in wheel plane, (m/s). 
v^Vi Lateral vehicle, wheel center speeds, (m/s). 

V Velocity, (m/s). 

tUx Vehicle roll angular speed, (rad/s). 

Wy Vehicle pitch angular speed, (rad/s). 

to. Vehicle yaw angular speed, (rad/s). 

X Body fixed longitudinal axis. 
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WACKER AND K£ANE: STRATEGY TO VERIFY CHASSIS a»fTROIXER SOFTWARE 


481 


X Global vehicle longitudinal position, (m). 

y Body fixed lateral axis. 

Y Global vehicle lateral position, (m). 

Y Vehicle side force, (N). 

z Body fixed vertical axis; height of roll axis 

above ground at axle, (m). 

Z Global vehicle vertical position, (m). 

a Tire side slip angle, (rad). 

P Vehicle sideslip angle, (rad). 

6 Steer angle of wheel, (rad). 

7 Wheel camber angle, (rad). 
/i Friction coefficient. 

u Angular velocity of the wheel, (rad/s). 

p Mass density of air, (kg/m^). 

4> Vehicle pitch angle, (rad). 

9 Vehicle roll angle» (rad). 

ij) Vehicle yaw angle, (rad). 

€ Roll steer {dSldB), (rad/rad). 

{dATIdo) CHiange in aligning torque versus slip, 
((N»m}/iad)- 

{dD/dF, } Change in rolling resistance with load, (N/N). 

{dL/dttfx} Roll damping produced by the shock ab- 
sorbers, {N*m*s)/rad). 

[dY/dy] Camber thrust per unit camber angle, (N/rad). 

[dj/d9] Rate of wheel camber angle diange with 
respect to body roll angle, (rad/rad). 

Subscripts: 

b Brake. 

fail Failure. 

/,r Front, rear axles. 

ifj tth, jih wheel and axle location. 

1, 2 Right, left front wheels. 

3, 4 Rigjit, left rear wheels. 


I. iNTKODUCnCHM 

THE application of on-board electnmic controllers to mon- 
itor and regulate automotive systems offers the consumer 
improved vehicle performance. Powertrain controllers mon- 
itor all major engine and transmissi<Hi functions to realize 
significant reductions in tailpipe emissions with minimum 
adverse effects on fuel economy and vehicle driveability. Body 
and chassis control systems (e.g., antilock brakes, real-time 
suspension damping) provide increased safety and ride comfort 
to the vehicle occupants through improvements in directional 
stability and steerability [1]. Traditionally, the development 
process for automotive systems has involved extensive in- 
vehicle testing and evaluation. However, the competitive de- 
mands of the marketplace are requiring automotive companies 
to reduce cycle time and development costs. The applicaticm of 
hardware-in-the-loop (MIL) technology to the controller design 
process can reduce expensive field tests, improve product 
quality, facilitate examination of subsystem interactions, and 
resolve critical safety issues prior to in-vehicle testing [2], In 
particular, the system level verification and validation of inte- 
grated chassis controller hardware/software to the customer's 
requirements can be automated in a laboratory setting with 
HIL tools. 


A HIL simulator permits an automotive controller to be 
operated in an environment electronically equivalent to the ac- 
tual vehicle (refer to Fig. 1). The simulator contains electronic 
circuits which provide electrical loads representative of those 
found in an actual vehicle. A high-speed computer is interfaced 
to the controller through the actuator and sensor emulation 
hardware. The computer executes dynamic system models to 
calculate the vehicle's response and generate sensor signals for 
the driver inputs and controller commanded actuator signals. 
Thus, a dynamic coupling is established between the controller 
and the simulated vehicle. In this paper, the hardware and 
software elements of an automotive chassis simulator are 
presented. Section II provides an overview of various vehicle 
subsystem models. The simulation computer and laboratory 
hardware are presented in Section 111. jn Section IV, the 
software utilities necessary to automate the testing process, as 
well as several methods to verify controllers, are discussed. 
Section V presents experimental and simulation results to 
provide insight into the application of the tool set A number of 
key simulation issues are discussed in Section VI that should 
be addressed eariy in the development process. 

II. Simulation of Chassis Dynamics 

The creation of a model-based automotive simulation re- 
quires the availability of empirical and analytical mathematical 
descriptions of the system components. As shown in Fig. 2, 
the chassis dynamics are generally composed of the vehicle, 
wheel, brakes, steering, suspension, tire/road interface, driver, 
environment, and in some instances, powertrain dynamics. 
The vectors Xi have been introduced to permit the primary 
output elements from each subsystem to be denoted. For 
instance, the brake system block has the output vector X2 
which includes the brake pressures and torques for each 
brake channel. The inputs to this subsystem include the 
variables from the engine, transmission, and engine control 
module (Xi), the ABS/TCS controller (Jfg), and the driver 
(Xxo) blocks. Models for each of the vehicle*s subsystems 
should be available with varying degrees of sophistication. 
The complexity of a component model may then be selected 
in order to create a simulation tailored for the application that 
is not overly excessive. This is an important issue in real- 
time simulations where a Uradeoff often exists between model 
fidelity and execution speed requirements. In the paper by 
Allen and Rosenthal [3], vehicle dynamics model requirements 
are summarized for various types of simulations. The chassis 
models ipresented in this paper are sufficient for software 
verification. 

The environment block contains software modules which 
allow the road surface properties and elevation to be var- 
ied as functions of the vehicle's location. For instance, a 
composite road surface may be characterized by specifying 
the friction coefficients in a position indexed lookup table 
[4]. The vehicle's global position is then used to determine 
the nominal coefficient of friction for each wheel. In the 
driver block, vehicle maneuvering information is described 
through traditional driver commands. These commands may 
be generated by the user during run-time by manipulating the 
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Fig. I. Cooccptual goal fof hardwaic-in-ihe-loop testing. 



Fig. 2. Schematic for simulating chassis dyiuunics. 


hardware inteiface» or stored a priori through the use of script 
files to automate Ae system's operation. 


A. Vehicle and Suspension Dynamics 

The motions of a vehicle may be categorized in terms of 
performance and ride, as well as handling and stability. The 
performance and ride characteristics focus on the longitudinal 
and heave motions of the platform, respectively. The stability 
and handling characteristics generally refer to the vehicle*s lat- 
eral/directional response due to steering maneuvers. A variety 
of low, medium, and high-order models are available to de- 
scribe the automobile's translattonal and rotational dynamics. 

I) Low-Order Models: A one degree-of-freedom (DOF) 
vehicle model is sufficient in cases where a lumped mass 
approach is acceptable to generate the platform's speed. The 


equation of motion in the longitudinal direction is 

mu = EF, (1) 

This description has been successfully used in powertrain 
simulations which require only an approximate speed to em- 
ulate the vehicle*s speed sensor for engine algorithm testing. 
However, limitations in the vehicle dynamics preclude the use 
of this model in chassis controller studies. 

A two DOF model is presented for lateral stability investi- 
gations. In this analysis, the vehicle's front and rear wheels are 
collapsed into a single firont (steerable) and rear wheel with 
negligible inertia. Also, the roll and weight transfer effects are 
neglected. This ''bicycle'' model permits the lateral/directional 
response of the platform to be examined for small angle 
steering maneuvers at constant longitudinal speed [5]. Body 
fixed (xyz) and global {XYZ) coordinate systems are used 
to describe the dynamics (refer to Fig. 3). The equations of 
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Fig. 4. DiiectioQal geometry and rotational wheel dynamics. 


motion for forces along the j^axis and moments about the 
z-axis are 


m(v + uu;,)=EFy 


(2) 
(3) 


As shown in Fig. 4» the wheel is rolling at a slip angle a 
which represents the angle formed between the direction of 
wheel travel and wheel heading. The front and rear slip angles 
become 

o/ = {v-hatUiJ/ti-S/ Or = :{v-6ti?i}/tt. (4) 

In some cases, a front and rear roll steer effect {e9) may also 
be included in the slip angle expressions. From this figure, 
P = [v/u} represents the vehicle sideslip angle. To further 
simplify the analysis, it is assumed that the slip angles are 
small (sin a = a) and that the lateral tire forces are linear 
functions of the slip angles. If the lateral accelerations are 
greater than approximately 0.4 g*s, then this final assumption 
may no longer be acceptable. The summation of lateral forces 
and moments about the yaw axis is 


In these equations, the cornering stiffness has a negative 
magnitude since a positive slip angle produces a negative 
lateral force acting on the tire [6]. However, in some references 
(e.g^ [7]), the cornering stiflfness has a positive magnitude 
resulting from its definition as the negative of [dFy/da], 
Equations (2) and (3) may be numerically integrated to yield 
the lateral and yaw velocities in the local coordinate system. 
These body axis velocities may be transformed into velocities 
in the global reference system by 

% = ucos^ — vsin^ K = tisin;^ + t;cos^ (6) 

where ^ is numerically integrated from ^ = u;,. Finally, the 
vehicle's position in global coordinates may be determined by 
integrating the expressions in (6). 

2) Medium Order Models: A three DOF model is presented 
to describe the longitudinal, lateral, and yaw motions of an 
automobile undergoing maneuvers [8]. This model combines 
vehicle kinematics, tire forces, and wheel dynamics to create 
a general purpose simulation suitable for preliminary antilock 
brake system (ABS) and traction control studies. The equations 
of motion are 


= OajQf + Co, Or EM, = aCofOt/ - 6Ca^Qr. (5) 


m{u - tmj,) = EFx 


(7) 
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in the longitudinal direction and (2) and (3). From Fig. 3» the 
external forces acting on the vehicle are 

4 

J:F, = 52f,. -Fd {where Fd = 0.5CapAfa'} (8) 

4 
i=l 

The sununation of moments about the yaw axis are 

EM, = o(F^ + F„) - b{F^ + F^) 

+ - F.. ) + d(F^, - F^). (10) 

In this expression, the aligning torques have been neglected 
and should be added if required. Equations (2), (3)» and (7) 
may be numerically integrated to determine the lateral, yaw, 
and longitudinal velocities in the body axis coordinate system. 

The speed of each wheel center in the wheel plane may be 
calculated as 

= UiCo&6i -i-ViSiadi (11) 

where the longitudinal and lateral velocities at each comer of 
the vehicle are given by 

=tt + (-l)*ciu, vi=v-hoti;^ (I2a) 
ti,= tt + (-l)'dii;, Vj=v-bw^ 0' = ^»4). (12b) 

Again, the vehicle velocity may be transformed from the local 
coordinate system into the global reference system using the 
transformations in (6). 

For completeness, a model developed by Segel [9] which 
analyzes lateral vehicle motion in response to steering inputs 
will be discussed. The assumptions for this model include 
a constant forward velocity, small lateral accelerations, and 
symmeuy about the x-axis which allows a single front and 
rear wheel to be considered. The equations of motion for the 
sideslip, roll, and yaw in a two mass (sprung and unsprung) 
system with an inclined roll axis are 

m{v + mi;,) + m^h^w^ = EFy (13) 
J^Wx + Tl»sh,(v + VWz) + J^Wz = SAf, ( 1 4) 
/«ttr,-l-J„ub=EAf,. (15) 

The lateral forces acting on the platf<Mm are 

EF„ = y> + Kr (16) 

where 

Yi = Ca^oi + {dYi/drMOyi/BB}^ 

includes the cornering force and tire camber effects. The 
chassis characteristic [dji/dB] is experimentally measured for 
the vehicle. The torques contributing to the roll moment are 

EAf. = (m,g)h,e + [ke, + k^^B + [{dL/dw^} f 

+ {aL/a«^},K. (17) 


In this expression, the roll damping produced by the shock 
absorbers may be approximated as [dL/dwx}i — 2de^li^, 
The summation of torques for the yaw moment are 

EM, = (oy>-6yr) + (:5T/+3Tr)+2(c5/ + £©r) (18) 

where 

M'i = {dATi/dai}ai and A = {dA/SF, J AF^ • 

The load transfer AFj^ may be calculated as 0(^^ + 
ke.e + {dL/dvh)iW^) with 0 = V{2c} or l/{2d} de- 
pending on whether the front or rear axle isjunder consid- 
eration. In the expressions for KiATj, and Ai the terms 
{dYi/dji},[dATi/dai}, and {BDi/dF^,} are empirically 
defined tire characteristics (Section II-B). Equations (16>-(18) 
may next be expressed as functions of (j9»ta„d,f/,Wx)* The 
resulting differential equations are traditionally solved with 
classical methods to study the influence of various design 
parameters on the vehicle's stability. The reader is referred 
to the reference by Mola [10] for further information. 

A four DOF model is presented to describe the longitudinal, 
lateral, yaw and pitch motions of an automobile. This model 
provides a general purpose description of the vehicle dynamics 
which can serve both powertrain and chassis applications well. 
The equations of motion are 

Iw^ = ^My (19) 

and (2), (3), and (7). The summation of forces and moments 
(refer to Fig. 3) are (9) and 

4 

EF. = -T/iysin0 + ^ F,, - Fj (20) 

£Af. = a(F„, + ifU) - KFy, + F^) + c(F:^ - F.. ) 
+ d(F^-F^) 

4 

- c(F^ +F^) + - F^) + ^ (21) 

4 

EM^ = -a(F,, + F,3 ) + 6(F„ + F, J + ^ W^., 4r ft«Fd. 

(22) 

The transformations to calculate the yaw, pitch, and approxi- 
mate roll angular velocities, based on tUy and Wa, are 

ip = Wz 4> = ^y 9 = Wt<l>. (23) 

These expressions may be numerically integrated to calculate 
the yaw and pitch, as well as approximate roll, angles. In 
a similar manner, the transformations to compute the global 
velocities 

X =uco8<#co8^ — t;sin^ y = vcos^ + usini;^cos^ 
Z = -«sin^ (24) 

may be integrated to determine the global positions. 

Depending on the intended application of the simulation, 
the model for the suspension forces may be simplistic or quite 
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complex. Generally^ a suspenaon Tnodel will include spring 
forces as well as viscous and Coulomb damping forces 


^1 ~ -^ipringi "I" -^damp, + ^^conlj • 


(25) 


The suspension springs (coil, leaf» or torsional bars) support 
the weight of the car and characterize the ride behavior of 
the platform. The spring force is a nonlinear function of the 
suspension's deflection. Frequently, a series of linear reg;ions 
are considered over the tange of vertical travel to approximate 
the nonlinear behavior. For the four DOF vehicle nK)del, the 
front and rear spring forces can be represented as (a^)^^ 
and —{b4)k^ where may be interpolated from a lookup 
table or further approximated by a constant magnitude. The 
term Fdamp represents the hydraulic shodc absorbers (or 
stmts) whid) dampen the vehicle's motion. In many analyzes, 
these viscous damping elements are modeled as ideal fluid 
dampers whose force is pn^K>rtional to the suspension's rate of 
deflection. Again, the nonlinear damping force versus velodty 
curve may be approximated by straight line segments. The 
front and rear damping forces can be represented as {aw^)d^^ 
and — (6uity}4^ where may be determined in a similar 
manner to k^. Finally, the coulomb damping force is also a 
function of the su^>ension*s deflection rate. This frictioh force 
is quidc acting and has a saturation feature normally described 
by limit functions. In some applications the rubber bushings, 
which act as vibration isolators to minimize transmission of 
higher frequency oscillations, and/or anti-sway bars may also 
need to be considered in the suspension model. 

3) High-Order Models: If a more sophisticated vehicle de- 
scription is needed to study dynamic interactions* then a 
higgler order model using sprung and unsprung masses is 
recommended. Two vehicle stability and control simulations 
are available to study bandlii^ and braking capabilities for 
a range of maneuvers. The simulation by Garrott and Scott 
[II] considers a three mass system — sprung, front un^rung 
and rear unsprung. The sprung mass has six DOF (three 
translations and three rotations). The unspnmg masses each 
have two DOF if the wheel spins and steering dynamics are not 
counted. The front unsprung mass has two translations relative 
to the sprung mass to describe the wheel hop. For the rear 
unspnmg mass, the independent suspension model includes 
two suspension deflections while the solid axle description 
considers one suspension deflection and one axle roll. Overall, 
this vehicle model provides a comprehensive description of the 
system dynamics. The second model has been developed by 
Allen et qL [12] to analyze vehicle lateral/directional control 
and stability. In this model, a three mass system is also 
considered. The sprung mass has four DOF (longitudinal, 
lateral, yaw, and roll) while each unsprung mass has two DOF, 
again not counting the wheel spins and steering dynamics. 
For the front and rear unsprung masses, the roll and vertical 
motion of the respective axles are considered. In additicm to 
modeling the vehicle dynamics, these two simulations provide 
descriptions for the wheels, suspension, steering, and tire/road 
interface. 

An important issue in the development of real-time sim- 
ulations is the tradeoff between model sophistication and 
execution speed. Ideally, all the system dynamics may be 


adequately addressed when developing a model. However, 
real-time requirements may challenge the engineer to exclude 
some dynamics in order to achieve a mathematical description 
which may be computed in real time. Associated with this issue 
is the correlation, or level of accuracy, of the simulation to the 
physical system for a specified operating range. Heydinger et 
al. [13] has proposed a statistical based validation methodol- 
ogy which requires multiple experimental and simulation runs 
at each test condition to gather data for both frequency and 
time domain analysis. A s^es of qualitative (e.g., overlaying 
plots) and quantitative (e.g., steady state gain, peak frequency) 
strategies are presented to compare the test measurements and 
simulation predictions. 

Tire/Road Interface 

The shear forces and aligning torques generated at the 
tire/road interface must be computed to simulate the wheel and 
chassis dynamics. To quantify the impact of applied braking or 
driving torques on a wheel, the tire's side slip angle and wheel 
slip are calculated. As shown in Fig. 4, a local coordinate 
system (z', 3^) has been attached to the wheel with its origin 
at the center of tire contact Although the side slip angle was 
introduced in (4), the expression is now stated as 


aj = tan (vj/ui) - 6i- 


(26) 


The longitudinal wheel slip is defined in two mannei^ dep'ehd- 
ing on whether the wheel is accelerating or decelerating 

drive slip: s,, = {uu,t - Rcii»>%)/J^i<*'i 

brake slip: = - -Rc<Wt)/ttur<- (27) 

To calculate the shear forces and aligning torques, the normal 
tire load must also be available. In the model proposed by 
Dugoff et aU [8], the static loading and quasistatic load transfer 
due to pitching, as well as the quasistatic approximation of 
the dynamic load transfer due to the vehicle's roll angle, are 
considered 

=0.5;|.(:^) [-«^5-h^E/x. ^KF^ 

-h {-l)^^'\ko,l{ke, 4- hMhF^c)^ (j = 1,2) 

(28a) 

-h {''l)^^^\k9j{kB, +fcfl.})(W^v/^| a = 3.4). 

(28b) 

Generally, the traction forces for a variety of road surfaces 
and operating conditions may be generated using two strate- 
gies: extrapolation of empirical data, and analytic models. In 
the first method, experimentally gathered tire data is loaded 
into look up tables and an extrapolation scheme [14] is 
implemented to describe road conditions that are not explicitly 
contained in the test data. Frequently, experimental tire data 
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is limited to a few road surfaces (e.g., dry asphalt, asphalt 
with thin water film) and operating conditions (e.g., side 
slip angle, normal load). Fnnn this experintenta] data, the 
longitudinal tire force versus wheel slip provides a measure of 
the braking/driving force coelScient {F^/Fx}. The lateral tire 
force versus slip angle graph provides the cornering stiffness 
Ca = [^Fy/da)a=0' The aligning torque versus slip angle 
and camber thrust versus camber angle graphs can yield 
{dAT/da} and [dY/d^], respectively. Fiially. the tire's 
rollmg resistance versus vertical load at a spediied forward 
velocity (»Y>vides the quantity [dD/dFx}^ 

The second strategy uses mathematical models to estimate 
the mechanical perfomiance of pneumatic tires from basic 
design and operating variables. These models range from 
simple linear descriptions useful in deriving and analyzing 
control systems to nonlinear representations [15]-(I7] with 
tire lag [18]. The tire forces and aligning torque are calculated 
based on the longitudinal wheel slip, wheel speed, side slip 
angle, nonnal load, and other variables (e.g., camber angle). 
These forces in the wheel plane may be transformed into 
longitudinal and lateral forces in the vehicle coordinate system 
by 

Pxi = Fxwi cos6i~Fy^.dxi&i Fy. = Fj^wi sia^i-hFj^. cos^i 

(29) 

C Wheel Rotational Dynamics 

The forces and torques acting on the tlh wheel from the 
transmission, brakes, road surface, vehicle, and wheel bearings 
are shown in Fig. 4. The summation of moments about the 
spin axis are 

I^Wi = Tfr, + Td, + F^,/i' - F^Ooff - C^,u>i. (30) 

Several approaches may be used to calculate the wheel speeds, 
including the direct integration of the rotational dynamics 
and a closed form solution based on the linearized ^-slip 
curve. In the first metiiod, (30) is numerically integrated. 
However, these dynamics are very fast compared to the overall 
vehicle dynamics which can result in stiff differential equations 
(i.c, system eigenvalues vary widely in magnitude). This 
phenomenon arises from the large mass and moments of 
inertia for the vehicle in comparison to the small rotational 
inertias of the wheels aixl large torques experienced from the 
braking, driveline, and ground forces. If the high-frequency 
wheel dynamics are not properiy handled, then numerical 
instabilities may arise. A number of solutions are available to 
avoid numerical integration stability problems. First, reduce 
the integration time step as allowed by the execution speed 
constraints. Second, select a numerical integration method 
with accuracy and stability characteristics suitable for the 
application. Improved accuracy may be realized by using 
smaller time steps or by selecting a higher order integration 
algorithm. However, higher order integration methods may 
have smaller stability r^ons which will require smaller in- 
tegration time steps. Third, consider restricting the simulation 
to avoid unstable domains of operation. For instance, an ABS 
simulation might terminate when the vehicle velocity falls 
below some specified threshold (e.g., V<1 MPH). Although 


this solution may be acceptable for ABS simulations since 
connrol algorithms cease operation in this region, it is probably 
not optimal in traction control studies where low vehicle 
velocities are of interest. 

The second strategy to simulate the wheel spin dynamics is 
based on the work by Bernard [19]. The nonlinear tire traction 
torque is linearized about the operating point ^ by considering 
a Taylor series expansion of the continuously differentiable 
/*-slip curve with higher order terms neglected (i.e., /i = 
/io+{^M/5sx}{«at-^xo})- This permits a closed form solution 
of the first order wheel slip equation to be obtained, thus 
eliminating the need for numerical integration. The underlying 
principle of the state transition approach may be used in other 
simulation applications where the diflerential equations do not 
readily lend themselves to numerical integration. 

D. Brakes and Steering Dynamics 

A base brake model should include descriptions for the 
pedal linkage, vacuum booster, master cylinder, brake lines, 
and brake discs or drums [20]. The pedal linkage transmits the 
driver's applied force to the vacuimi booster which amplifies 
this force using vacuum from the engine's manifold. The 
master cylinder, attached to the vacuum booster, transfonns 
the amplified force into hydraulic pressure by displacing brake 
fluid through the front and rear brake lines. Proportioning 
values distribute the pressure properiy between the front and 
rear axles. The front and rear brakes convert the pressure into 
a friction force to decelerate the wheel. Although the brake 
system is nonlinear with dead zones, approximate models (e.g., 
pure time delay, first order linear dynamics) are frequently 
used to describe the system*s response. However, nonlinear 
models of the vacuum booster, master cylinder, engine mani- 
fold, and proportioning values have been developed (e.g.» [21] 
and [22]) which offer improved accuracy. 

The steering module maps the steering wheel inputs into 
firont wheel displacements. Manual steering systems contain 
a steering wheel and column, a gearbox and pitman arm or 
a rack and pinion assembly, linkages, steering knuckles and 
wheel spindles [23]. Power steering systems add a hydraulic 
pump and power steering gear assembly. In the model derived 
by Segel [24], a distributed mass steering system is reduced to 
a lumped mass description with compliance, Coulomb friction, 
and viscous damping. The inputs are the driver applied steering 
torque and kingpin torque due to the tire/road interface, 
while the output is the front wheel displacement. The model 
proposed by Garrott and Scott [11] calculates the front wheel 
steering angles and steering conneaing rod displacement as 
functions of the steering wheel angle, moments on the wheels 
about the kingpins, linkage geometry and stiffness, and gear- 
box ratio. In some instances, the steering system dynamics may 
be avoided by assuming an infinitely stiff steering mechanism 
and by directly providing the front wheel displacements. 

E, Engine and Transmission Dynamics 

A variety of models have been derived to describe the 
behavior of spark ignition (SI) and diesel engines for sim- 
ulation and conb^ol purposes. A comprehensive survey has 
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been conducted by Powell [25] on internal combustion engine 
models for controt system design. The engine descriptions 
may be broadly divided into input-output and physical-based 
models. Multi-input multi-output models are generated by 
applying system identification techniques to tite experimental 
data (e.g., [26]). The resulting transfer functions are dependent 
on the specific system configuration, and require erigine data 
to be avaikible over the full operating spectrum. The physical- 
based models consider fundamental laws governing the f)ows» 
thermal transients, and accelerating inertias to describe the 
behavior of the system components. For real-time HIL test- 
ing, the lumped parameter mean value engme models (e.g., 
[27H33]) may be selected as the basis for engine simulations 
due to the saiisfactoiy accuracy and limited complexity. For 
diesel engine models, the reader is referred to the work by 
Benson [34], Watson [35), and Kao and Moskwa [36). A 
number of subsystems are generally considered in a tur- 
bocharged diesel engine description including the compressor, 
tntercooler, intake manifold, engine and crankshaft assembly, 
exhaust manifold, turbine, and turbocharger rotor. 

Analytical and empirical models in the emulation library 
describe the fiiel injectors, throttle body, intake manifold, com- 
bustion inocess, and rotational dynamics for SI engines [37]. 
The fuel injector model omverts the controller commanded 
solenoid fuel pulses into a mass of sprayed fuel. The dirottle 
body model onnputes mass mr flow rate into tfie intake 
manifold based on the throttle valve angle, idle air control 
actuator position, and pressure ratio across the throttle. The 
intake manifold dynamics distribute and delay the flow of 
gases from the throttle body and EGR valve into the engine 
cylinders with attention to fuel transport characteristics, if 
appropriate. The combustion model generates the indicated 
torque based on the mass of air, air/fuel ratio, spark timing, and 
exhaust gas in each cylinder. Finally, the crankshaft torques 
(e.g., indicated and bad) are summed, integrated, and divided 
by the crankshaft inertia to yield the engine speed 

An automatic transmission transfers and regulates die en- 
gine's power to the drive wheels based on the vehicle's traction 
requirements. A numt>er of models and analysis methods 
have been proposed to describe the behavior of vehicle trans- 
missions. The interested reader is referred to the references 
by Benford and Leising [38], Kotwicki [39], and Cho and 


Hedrick [40]. The transmission modules in the simulation 
library include the torque converter, transmission gearbox, 
and differential [37]. The torque converter provides a fluid 
coupling between the engine and the drivetrain to dampen 
out disturbances, prevent engine stalling, and provide torque 
multiplication during vehicle acceleration. To describe these 
dynamics, the empiripal based torque converter models gen- 
erate the pump and turbine torques based on their respective 
speeds. Included in this subsystem are the torque converter 
clutch models which describe the mechanical linkage of the 
pump and turbine. The automatic n^smission gearbox models 
describe the motions of the planetary gears, clutches, and 
bands which together provide different torque multiplication 
ratios based on the engine load conditions. The differential 
models contain the kinematics of the gears which provide 
additional torque multiplication, transmit the output torque to 
each axle, and allow different axle rotation speeds. 


III. SiMULAnoN Computer and Laboratory Hardware 

The real-time HIL simulation facility has been designed to 
test and analyze automotive controllers. As shown in Fig. 5, 
the facility consists of a simulation computer, various hard- 
ware interfaces, and controller instrumentation. The simulation 
computer is an Applied Dynamics Real Time Station (KTS) 
with an attached System 100 input/output (I/O) rack. The 
computer hardware is based on the open architecture of the 
VMEbus with distributed processors to execute the simulation 
models and handle network communications [41]. The RTS 
contains multiple Motorola 88110 based compute engines to 
solve the analytical and empirical mathematical descriptions of 
the system components. In the current configuration, the I/O 
rack contains analog-to-digital converters, digital-to-analog 
converters, and digital input/output lines. These intelligent 
I/O modules contain Motorola 68040 support processors for 
parallel computing of interface operations such as signal 
conditioning and linearization. The availability of commercial 
I/O modules to emulate automotive sensors should minimize 
the need for specialized hardware interfaces. A local 300 MB 
disk can support high-speed data recording and playback in 
real time during and after a simulation. 
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Users can access the RTS, a server attached to the local area 
network, from their workstations connected to the ethemet In 
our facility, Sparcstations 20 (model 50) are used to control 
and monitor the simulation, as well as provide an integrated 
environment for algiMrithm development and data analysis. The 
RTS compute engines can be programmed in C, Fortran, or 
Adsim [42]. A rapid prototyping capability is available to 
move quickly from block diagrams and software simulations 
(using Integrated Systems* MATRIXx product family) to HIL 
applications on the RTS. The high-level language Cosira is 
used to schedule, synchronize, and control communications for 
the parallel processors. Interactive run time software provides 
an environment to acquire simulation data, and to monitor and 
control the simulati(»i firom the user's workstation. 

A. Hardware Interfaces 

The hardware interfaces are designed to create an electronic 
environment equivalent to the vehicle. Ideally, the controller 
should be unable to distinguish between vdiicle and lalN>ratory 
operation. Thus, a controller should receive the expected inputs 
(e.g., commanded throttle position, wheel speeds) necessary 
for normal operation, while also delivering the required outputs 
(e.g., fuel injectors, trananission force motor). As shown 
In Fig. 5, the powertrain simulation (PSI), antilock brake 
(ABI), and motor load (MLI) interfaces provide the electrical 
transitions needed to connect controllers to the I/O rack. 

The PSI contains circuitry designed to accommodate engine 
and transmission controllers^ while the ABI electronics are 
targeted for chassis controllers. The PSI and ABI perfonn 
three types of operations on the I/O signals that pass between 
the controller and the RTS: analog and digital signal condi- 
tioning, the conversion of signals to different formats, and 
interconnection without modifying the signal. The first type 
of operation, signal conditioning, is applied to outputs from 
the controller (e.g., high-side drivers) or the RTS (eg., low- 
side switches). An example of the second type of operation is 
the conversion of a pulse width modulated controller output 
to a voltage proportional to its duty cycle. In the third 
category, circuits pass select unconditioned controller signals 
(e.g., serial data) to an output port An important consideration 
for the circuits in the first two categories is the provision 
of electrical loads equivalent to those found in an actual 


vehicle. However, these electrical loads cannot be easily 
adjusted to permit the introduction of signal shorting or noise 
disturbances. Consequently, a failure mode interface (FMI) has 
been designed. An attractive feature of the PSI is the ability 
to select between a front panel or RTS automated mode of 
operation to control the generation of signals. The user may 
either drive the HIL simulation by manually manipulating 
the simulator's switches and potentiometers, or place it under 
computer supervision (Section IV-A) to execute a test profile 
composed of driver commands. 

The MLI provides an electrical load and interface circuitry 
between ABS VI controllers and the simulator. The electro- 
hydraulic ABS VI modulator regulates brake pressure in each 
channel (left front, right front, and rear) using a dc motor 
attached to a power screw which extends/retracts a piston to 
push/pull brake fluid. The MU allows the simulator to exercise 
the controller's software in a realistic manner while applying 
reasonable electrical loads to the controller's hardware. This 
interface uses a static resistor-inductor (RL) network to load 
the motor driver circuits thus permitting the controller to 
realize its commanded motor current During a simulation, 
the comnnanded motor current tc is measured by the MLI 
and provided as input tc to the motor driver model executing 
on the simulation computer (refer to Fig. 6). This model is 
coupled with descriptions of the dc motor, ABS modulator, 
and vehicle to calculate the estimated **actuar motor current 
iat as well as the brake pressure and the chassis' response. 
To accept the ^actual" motor current feedback signal from the 
simulator, rather than from the on-board motor driver circuit, 
the controller hardware must be modified (i.e., cut and jump). 
The MLI's approach to simulating dc motor loads through the 
use of static loads on the driver circuits and hardware-intrusive 
feedback avoids die difficulties associated with emulating the 
back-emf in hardware while retaining the effects of a dynamic 
load on the controller. 

The FMI provides a computer supervised method for the 
hardware-based manipulation of the controller I/O. This instru- 
ment is positioned between the three hardware interfaces and 
the controller so as to modify the cable harness signals. The 
FMI provides two basic operations — signal shorting and signal 
summation. The signal shorting circuit offers four options for 
an input signal C: closed circuit, open circuit, short to ground. 
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and short to battery. The signal summation circuit introduces 
four capabilities for two input signals, A and B: closed and 
open circuits for A, replacement of A with B, and signal 
summation (A+B). An important feature of this instrument 
is the ability to automate its operation. High-level software 
directives may be specified in scheduler files to regulate each 
circuit, as well as to generate the additive or auxiliary signal B. 

B. Controller Instrumentation 

The Modular Development System (MDS) has been de- 
veloped by Delco Electronics to support software testing 
and calibration activities. This instrumentation provides three 
primary capabilities when connected to a controller emulation 
of program and data mennories, high-speed data acquisition, 
and internal data logging. A personal computer (PQ provides 
the interface between the user and the MDS. The PC uses 
rc/NFS software to access the ethemet and permit remote 
operation of the instrumentation. The architecture of MDS 
enables the instrumentation's RAM, which emulates the con- 
troller's ROM. to t>e asserted in the controller's address space. 
Thus, the PC to MDS path allows ttie transfo^ of files (e.g. 
program code, calibration sets) to the instnmientation, thereby 
providing an alternative to programming controll^ memory 
devices (e.g.. EPROMS). 

The high-speed data acquisition and internal data log- 
ging capabilities of MDS are impc»tant tools for software 
development By overlaying the controller's RAM with instru- 
mentation RAM, the MDS captures data from the controller 
without disturbing its operation. The data is logged to a 4 MB 
RAM buffer in the computer interface buffer with internal 
logging (CIBIL). To synchronize flight recording operations 
for multiple data acquisition systems, an external triggered 
input and a system triggered output are available. During a 
test, the preselected controller variables are logged, processed, 
stored in RAM, and di^layed on the PC or vacuum fluorescent 
display unit At the conchision of the test, this information may 
be transferred from the CIBIL to the Sun worfcstatioit 

IV. ALrrOMATlNG THE CONTROLLER TEST PROCESS 

The development of software utilities to automate the con- 
troller testing process enhances the attractiveness of simulation 
tools. A computer supervised scheduler enables the controller 
inputs and simulation events to be prescrilied in a repeatable 
manner through script files. To record the controller's response 
to this stimuli, data is logged from Iwth the simulator and 
controller with the integrated data acquisition scheme (Section 
IV-B). Several test methods have been developed to facilitate 
the systems level verification and validation of integrated 
controller hardware and software. 

A. Scheduler Utility and Test Scripts 

The scheduler utility has been developed to schedule spe- 
cific events (ic, controller inputs, driving scenarios, and/or 
instrumentation citations) in a time indexed manner. This 
utility reads the user specified inputs or recorded in-vehide 


test data from the designated scheduler file and, at the appro- 
priate time instances, updates its outputs. A schedule file also 
contains information to direct the operation of the simulation 
environment and control the data acquisition process. Eadi file 
chronologically lists the simulation variables to manipulate, 
with dieir prescribed profiles, and the controller and RTS 
variables to be acquired through data acquisition. During 
execution of a simulation, the designated schedule file contents 
are loaded into the simulation and interpreted by the scheduler 
utility. The scheduled variables' signals are generated by the 
utility's software-based Ainction generator (e.g., step, saw 
tooth) at the times specified for each variable. 

To support a variety of driving profiles and test procedures, 
a number of schedule files must be created. In most instances, 
a schedule file is designed to verify one requirement in the test 
plan. Thus, a logical extension to the schedule file concept is 
the creation of test suites for systems and software verification, 
The grouping of these files into a series of test suites, perhaps 
organized by software functions or features, facilitates regres- 
sion testing (i.e., selective retesting of a system to ensure that 
a software change has not caused unintended effects in another 
area). Ideally, the schedule files and test suites developed for 
one program will be directly applicable to future programs. 

Integrated Data Acquisition 

An integrated data acquisition strategy has been created to 
time synchronize the data from the connx>tler instrumentation 
and the simulation computer (refer to Fig. 5). Controller 
hardware and software may be effectively investigated by 
analyzing the controller's internal variables, external I/O, 
and appropriate simulation variables. For instance, a split 
coefficient braking maneuver can be established using the 
scheduler utility. An ABS control algorithm's performance to 
this operating scenario may then be recorded and evaluated 
by logging controller data (e.g., estimated wheel slips) via the 
instrumentation, plus the vehicle dynamics (e.g., yaw angle) 
and c(mtrol]er I/O (e.g., wheel speeds) via the simulation 
computer. 

The Sun workstation is thcfinal. destination for the RTS 
and MDS data. During a test, simulation data is continuously 
acquired through the RTS data acquisition utility and written 
to a workstation file. Meanwhile, controller variables are 
logged to the CIBIL and stored in RAM. In addition, the 
instrumentation sends synchronization signals to the RTS to be 
included with the simulation data. Once the test is completed, 
the MDS recorded information is transferred to the workstation 
and written't'o another file. These two data files are aligned and 
merged to create a single data file that documents the test. 

C Controller Test Strategies 

The simulation facility provides a powerful tool for the ver- 
ification (i.e., the process of evaluating a system to determine 
whether the products of a given development phase satisfy the 
requirements imposed at the start of that phase) of electronic 
controllers. Three strategies, labeled open-loop, closed-loop, 
and hybrid, have been developed for systems integration test- 
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ing P7). The open-loop method directly provides specific input 
sequences to the controller using the scheduler utility. Not- 
mally, various automotive sensors provide these inputs ba^ 
on the vehicle's powertrain and chassis dynamic behavior. 
Therefore, this test strategy assumes that the vehicle's response 
may be neglected^ compensated for, or characterized by the 
prescribed controller inputs in the script files. The closed-loop 
method accepts driver inputs and controller outputs through 
the hardware interfaces to calculate the automobile's behavior 
on the RTS. The advantage of this strategy resides in the 
dynamic coupling of the vehicle dynamics and electronic 
controller to create an environment similar to the actual 
vehicle. Appropriate analytical and empirical models may 
be selected from the simulation library to create a suitable 
dynamic environment. The closed-loop scheduler test files will 
contain driving profiles characterized by typical driver cono- 
mands* Finally, the hybrid test method directly manipulates 
select controller inputs per the open-loq> method, while a 
closed-loop operating scenario produces the remaining sigrals. 
This methodology is beneficial in cases where the complete 
set of controller inputs cannot be prescribed, and physical 
relationships must be relied on to generate the remaining 
inputs. 

The simulation laboratory also provides an environment to 
support the design of control strategies and the validation of 
control systems. The stability, sensitivity, and robusmess of 
proposed control schemes may be investigated by exercising 
the algorithms in a closed-loop maimer on the simulation 
computer without hardware. Control systems may also be 
validated (i.e^ the process of evaluating a system at the end 
of the development process to determine whether it satisfies 
the overall systems functional requirements) in this laboratory 
enviroiunent. However, the correlation of the results with 
vehicle test data will depend on the accuracy of the various 
system models, as well as the emulaticm of the actuators and 
sensors. Thus, HIL tools should be viewed as a supplement to 
experimental testing. 


V. APPUCATION OF THE 

HarowarE'In-the-Loop SiMUuvnoN Tool Set 

Experimental and simulation results are discussed to provide 
insight into the underiying system dynamics and application 
of the toot set Multiple ABS controller variables will be 
presented for an in-vchkle ABS stop, a HIL laboratory sim- 
ulation of the ABS maneuver, and the HIL verification of 
a representative system soRware requirement The in-vehicle 
experimental ABS testing was performed in a Saturn SL2 
sedan. A description of the antilock brake control system's 
operation and components may be found in the Saturn service 
manual [43]. A number of tests were completed for various 
. road surfaces and vehicle speeds; an ABS stop on dry asphalt 
will be presented. The vehicle was traveling at a speed of V = 
55.0 MPH on a straight course when the brakes were applied 
at — 11.70 s. The data collected was limited to the controller 
variables and sutus bits available through the data logger on 
the MDS instrumentation. In Fig. 7, the brake switch, right 
front (RF) wheel speed (in MPH), commanded RF solenoid 
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Fig. 7. tn-vehide ABS maneuver. 

valve state, and RF commanded current (in amperes) are 
displayed. The discrete signals indicate inactive (open) and 
active (closed) states when the brake switch (solenoid lines) 
have a magnitude equal to zero and unity, respectively. For 
convenience, the data is presented between 11.0 s and 16.0 
s to highlight the ABS stop. In this test sequence, the road 
conditions could not be rigidly controlled which resulted in 
varying surface texture (i.e., no type of uniformity can be 
guaranteed), irregularities, and presence of small debris (i.e., 
stones, gravel, etc.). Therefore, it will not be possible to rigidly 
match the simulation results to this road surface due to these 
nonlinear effects. 

A HIL simulation was created to support software verifi- 
cation at the systems level for the ABS controllers. During 
the tool s^ development phase, the agreement between the in- 
vehicle and the laboratory simulation results was investigated. 
The appropriate brake modulator, vehicle, and tire/road inter- 
face parameter databases were loaded into the model-based 
simulation. Operating scenarios were created in the laboratory 
similar to those performed in the field. The scheduler utility 
permitted the repeatable simulation of a vehicle traveling at 
approximately V = 55 MPH with the brakes applied at 
it, = 11.70 s. The MDS data logger acquired the same set 
of controller variables and status bits (refer to Fig. 8). To 
compare the in-vehicle and HIL simulated ABS test results, 
several characteristics (e.g., total stopping time, wheel speed 
profile, and commanded current features) will be examined. 
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Fig. %. Haidware-in-the-toop smiulatioo of the ABS maneuver. 


Fig. 9. Hardware-in-the-loop verification of an ABS controller diagnostic. 


The elapsed stopping times for the in-vehicle and simulated 
RF wheels are 3.16 s and 3.07 s, respectively. Note that the 
wheel deceleration is approximately 26.0 (iVs^) or O.S ^'s 
for the given road surface. The number of impending wheel 
lockup and recovery events is approximately six for each case. 
However, the in-vehicle data also contains a number of minor 
departures, absent from the simulated results, which may be 
partially attributed to nonlinear effects and high-frequency 
unmodeled dynamics. The commanded current profiles for 
the initial ABS release and apply are similar in magnimde 
and duration for each case. The subsequent apply and release 
events differ between the in-vehicle and bench results due 
to the nonlinear and unmodeled dynamics, and the use of a 
different software calibration database which varied the mag- 
nitude of the incremental commanded motor current Overall, 
the simulation results agree fovorably with the in-vehicle test 
results. 

To provide insight into the application of the tool, a short 
to banery diagnostic fault [43] will be verified for the RF 
hydraulic bypass solenoid. During an ABS maneuver, the 
controller provides banery voltage to close the solenoid valve 
and isolate the brake pedal input Shorting the RF solenoid to 
battery voltage should cause the controller hardware to set a 
fault bit which results in the software disabling of the ABS 
modulator, setting diagnostic code 78, and illuminating the 
ABS telltale light To verify the diagnostic, a scheduler file 
was created to introduce this fault via die FMFs signal shorting 


circuitry. The controll^'s variables, as well as the commanded 
FMI introduced fault, were recorded during the simulation. In 
Fig. 9, the brake switch. RF wheel speed, RF solenoid valve 
state, FMI short to battery status (inactive when the magnitude 
is —1), and malfunction 78 flag are presented. The introduction 
of a RF solenoid short to ground at = 12.45 s during 
braking results in the immediate disabling of the ABS system 
and setting of malfunction code 78. 

VI. Observations 

A number of observations have been made during the 
development and application of simulation tool sets at Deico 
Electronics. The comments are restricted to simulator re- 
quirements, system hardware/software, and the establishment 
of metrics. Although these categories are not exhaustive, 
they include issues that should be considered early in the 
development process. 

A, Simulator Requirements 

A comprehensive set of requirements is essential to identify 
and develop appropriate solutions to meet the simulation 
needs. A variety of simulation products exist ranging from 
PC's with plug in cards to powerful simulation computers 
with extensive I/O functions based on VMEbus architecture. 
Clearly, sophisticated models will require a simulator with 
sufficient compute power to calculate the dynamics in the 


IEEE TRANSACTIONS ON SYSTEMS, MAN. AND CYBERNETICS— PART A: SYSTEMS AND HUMANS. VOL 27. NO. 4. iULY 1 W7 


allotted time period. Further, a simulator should be viewed 
as an integral part of the computer aided engineering process 
with provisions for rapid prototyping. 

B. System Hantware/So/hvare 

The hardware interface represents one of the laiger expenses 
incurred when developing a simulator. Although vendors now 
ofler a variety of interface circuits, the electronic functionality 
required by an application may not be available. Consequen- 
tially, the cost of in*house development (e.g., materials and 
engineering time) or the procurement of conunercial sohitions 
must be included in the budget. When designing an interface, a 
building block approach widi software reconfigurable circuits 
is recommended. 

Software maintenance is a continual task during the life 
cycle of the simulator. A laige programming effort will be 
required to create the simulator's software utilities during the 
development phase. To apply the tool set, appropriate system 
models with the required databases should be available on-line. 
In most instances^ modifications to the plication software 
will be regulariy requested to facilitate testing. 

C Establishment of Metrics 

Often the application of sophisticated technologies to the 
product development process must be justified by quantifying 
the cost savings. To measure the direct and indirect benefits 
of a simulation capability on product design and testing, 
appropriate metrics must be established. Some measurable 
quantities that may be selected include changes in manpower 
requirements, level of experimental or in-vehicle testing, and 
warranty return rates. 
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Abstract 

There is considerable interest io the automotive 
industry in computer aided engineering tools that 
support rapid development of quality (aoducts. In diis 
paper, we describe some of the design and 
implementation issues for such a tooL namely^ a 
Haidware-io-the-Locq) (HIL) simulator, in the context 
of powertrain control system software dcvdopncnt. 
This HIL system is used to verify tte production 
powertrain omtroller module (PCM) perfcnmance. 
Hence, the powertrain and drivetioe dynamics are 
simulated on the HIL hardware and the production 
PCM is the ^liardwarc^ tn the loop. HIL system 
requirements from the users* and the system 
developer^s perspectives are described. Use paper 
focuses on important HIL issues related to the real-time 
powertrain models and the hardware signal inter&ces. 

L Introdnctloo 
Automotive engineers are being challenged to i^ver 
higher quality [Roducts faster with ever sfaxinkiog 
resources for global markets with disparate eimsston 
regulations and custtnncr cjipcctatiocB. The design and 
implementation of oontrol algoriduns is a crucial 
elment in the development of powertrains to meet 
dwse requirements Ad-hoc heuristic design and 
implementation methods are bei^g replaced by 
systematic, requirenKnts driven processes. Vehicle 
requirements are cascaded down tt> powertrain system 
requirements which in turn generate iiMtividual engine 
and transmission sub^stem requiremeids. The goal of 
d>e powertrain control system (teveiopme&t ivooess is 
to generate a production quality control system that will 
be cafihrated by system engineers to meet powertrain 
and vehicle requiremeids in difPerem markets. Due to 
intense competitive pressures, the deveJopmcnt tunes 
are bdng shortened consxterably. The goals of 
ddivcring a quality product with reduced **time to 
martof* constraints caiuiot be successfully met unless 
modem computer aided tools are jucficiously used in the 
development process. This paper descrit)es some 
importam issues io the design and devetopment of one 
such tool used in powertrain control system software 
developmcm. 
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Since the PCM hardware is ofteo developed in parallel 
with the control algorithms and the vehicle subsystems, 
developers have little dme to test and verify the control 
algorithm implementations. Currendy, control systems 
are developed and tested using open loop testers and 
(BOtotype vehicles. The final system vialidation 
(confbnnance to requirements) is £Jso performed in 
prototype vehicles at various geographical locations to 
ensure that the controller algorithms are robust Open 
loop testers have limited functionality for scrflware 
testing sbice the developer cannot simulate the overall 
system feedback loops (c^^ resulting engine torque 
and q>eed as a function of changes in spark advance 
and foel iiyected). If a *Mrtual vehicle" were available, 
a significant part of software verification and system 
validation could be completed in a laboratory 
cnvirozuneot 

Hardware-in-lhe-Loop (HIL) simulation systems 
provide such a *\irtual vehicle** for system validation 
and verification. Diflerem HIL configurations have 
been described in the literature for different user 
applications (1,4] based on the *1iardware" that is "in 
the loop"*. The specific HIL system described here 
includes the powertrain control module (PCM) in the 
loop, while die powertrain dynamics, the sensor and 
actuator behaviors are simulated in die computing 
platform and interfeoe circuitry. The PCM **thinlcs** it is 
in a car, and this allows engineers to validate die 
oontrol system b^vior in a *Virtual vehicle** 
environment In addition, die contnriler behavior can be 
validated at various environmental conditions and die 
controller robustness can be tested by introducing 
powertrain component and subsystem malfunctions. 
White a HIL simulator will itot obviate the need for 
traditional test methods, it does albw developers to test 
the system in a repeatabte laboratory environment As a 
result, developers can identify and resolve problems 
earlier in die develc^mient cycle. 

As with any system developmem. the design of HIL 
systems should be driven by requirements. Some of 
these high level requirements are described in the next 
section. There are several hardware and software issues 
that are important fcHr a successful HIL imptementaiion. 
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The paper is focused oa those telaled to rcal-tiine 
powertrain modeling and signal interfecing and 
oonditiomng. A majority of the syston design activity 
involves sorting out these issues and thcrefoit ments 
detailed discussion. 

2. ReqiDraneots for the HIL System 
Since system requirements drive the design and 
tnfhiencc trade-offs, careful attention has been paid to 
die task of collecting requirements. Requirements can 
be categorized as those from the end user and those 
relating to system dcvch^mscnt and maintenance. 
Akmg widi diese requirements, die available tcsources 
and system costs will significantly impact the design of 
die system* Some of die high levd requirements are 
generic and are independent of the specific poweitrain 
an>lication. These include: 

1. The sy^em should be flexible so dot it can be used 
in multiple applications with minimal changes* 

2. The system should have sufficrem fidefi^ so that 
cMlroUer ntalf\inctk)os are only triggered unttt 
the same conditions as in the vehicle. 

3. System debugging toob shouU be available to aid 
the end user as well as the system devdi^}crs. 

4. The models should be impletncnted in an easy to 
use environment that pennits reuse and exchange 
of oomponem models between architectures. 

5. The computatioraJ ptetfom should be expandable 
to permit future growth widKWt advetsdy affectiog 
the real time dBOugbput <^ dkc system. 

6. Use of commercial ii^MtAwtput cards with 
minima] customization is desirable; 

7. Hard war e and software interfaces shoM be ''user- 
friendly* so that the end user is comfortable using 
the system, 

8. A modular interface to the controller^ physical 
agnals b necessary to enable cost ^ective 
modifrrations, when required. 


User Interface 


z 




ODOtioUcr 
iBierfaceBox 

4 » 

1^ Ik4^UU« 

**H<w Jwaic io 

Platfonn 



fbelsop** 


Hguiel: HIL System Componettts 


3L Configuring and Imptemcnttng an HIL System 
Besides the generic requirements described above, 
there may be application specific system requiremeots. 
Ail of these requirements should be taken into aocoum 
in the MIL design and implementation process. A block 
diagram representation of die HIL systrai is shown in 
Hgure 1. The following key process steps are involved 
tndevdq)ingsucha system: 

• Identify the specific PCM expectations. 

■ Identify the HIL computational platform. 

• Identify the modeling tool and generate "HIL 
oriented powertrain system models". 

■ Identify, partition and implement interface signal 
transfbrroations and electrical characteristics. 

■ Develop standard test suites 

• Implement an appropriate hardware and software 
user interface 

Although each of the aforementioned topics is 
important enough to warrant a thtmnigh discussion, diis 
paper focuses on two of those topics, namely, the **HIL 
oriented powertrain system models" and signal 
ooncfitioningand interfacing. 

4. HIL oriented Pbwertrahi System Model 
A large part of the HIL devdopmem effort is dedicated 
towards assembling a powertrain behavior model. This 
vaay involve modifying and adapting existing models as 
well as developing new models. The real-time 
simulation models share some unique properties that 
include: 

• Models include sufficient dynamics to meet the 
requirements of the PCM, but are not detailed 
enough for design purposes. 

■ Systems are typically represented by algebraic or 
ordinary differential equations. 

■ bi^ylicit equations or algi^raic loops are not used 
in the niodels, because these representations 
require an iterative sohition prt>ces5 and die real- 
time nature of HIL systems requires finite 
compulation times. 

■ Fixed step size explicit schemes such as Euler» 
trapezoidal or Runge-Kutta mediods are chosen as 
the integration algorithm. 

■ Unnecessary units or scaling conversions in the 
model are eliminated to reduce computational 
burden. 

Typically, HIL system models are adapted from 
hardware or control system design models and are 
modified to conform to the above requirements. In 
addition, the models may be extended to react to user 
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triggoed faults. Hie ntodds havt been devctoped in 
SIMUUNK*and* STATEFLOW™. 

4. 1 Model Architecture Deflnitton 

One of the first steps in the modeling process is the 
development of a system model architecture. The 
model architecture defines and estatritshcs the various 
functicma] units and the signal interface between the 
units in the model. During the architecture deHnition 
process^ the structural decompositioD of the model is 
also decided. At the root level, the model has been 
partitioned into User Inputs, PoMi^ertraio Systems, 
Actuaton and Sensors. The Powertrain Systems unit is 
further partitioned into Engine, Driveline, Catalyst and 
Accessory Loadl Engine Sensors* Drivdine Sensors 
and Accosoiy Loads Sensors make up the Sensors unit 
Similarly, die Actuators model unit is partitioned into 
Engine Actuamrs* Driveline Actuators and Accessory 
Loads Actuators. The Actuators and Sensors are 
connected toliqmt and Output Hardware Interface units 
respectively. The Hardware Inter&ce units consists of 
specific models of the cards. These models are 
supplied by the (datform provider and can be 
programmed easily from the standard SIMULINXT 
user interface. The User Inputs unit has all the model 
elements (including GUIs) for an interactive 
experiment session* 

4.2.MoMI>escr4itioD 
Typical control oriented models provkle adequate 
fidelity for control software validation. Modeling 
standards and rules regarding labeling^ units^ ranges and 
data types have been established and doraimfntrd 
These standards will be invahiable while using and 
iqtdating the models. The models are discretized at a 
sample rate of 1 millisecond for the real-time 
implenttntatitm. A teief descriptioa of the important 
sub-iTMxlek follows^ 

Bngbie: Thb stmuhtion model generates key variables 
such as engiric speed, brake torque, intake and exhaust 
manifoU pressures, mass air flow through the erigine, 
air-fiiel ratio of the con^>ustion mixture and exhaust 
temperanire and emissions. Modeled subsystems 
indude mtake manifold dynamics, fuel wall wetting, 
engine breadiing, intake to powerstroke delay, torque 
generation, exhaust temperature and pressure dynamics 
and fcedgas emissions {2,5,7]. 
Drivettne: The driveline simulation includes models of 
the torque converter, transnussion and the driveline 
dynamics. The torque converter model, which consists 
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of algebraic relationship between pump and turbine 
torques and dietr rotational speeds, provides die load 
torque to the engine and torque to the downstream 
components. The drive shift dynamics models die shaft 
torque and turtrine speed as a function of the turbine 
torque and driven wheel spted. The driveline inertia is 
lumped into single inertia elemrats for each of the 
gears in this model The longitudinal dynamics model 
calculates the vehicle and wheel speeds. 
Catalyst: A three way catalyst model emulates the 
behavior of die exhaust after-treatment system. Key 
elements include an oxygen storage model, catalyst 
effictency model and a catalyst warm*up model (3|. 
Accessory Loads: Accessories such as air conditioner 
clutch and a power steering pump are modeled to 
generate appropriate loads on the engine crankshaft so 
diat realistic engine cranking and start up behaviors, are 
simulated. 

Actuators and Sensors: The actuators and sensors are 
the key dements in the model architecture and 
transform physical quantities into electrical signals 
required by the FCM. The actuator and sensor 
electronics can be simulated either in the interface 
hardware or in the SIMULINK^ environment. The 
mechanical elements of the sensors and actuators are 
modeled in SIMUUNK*. The mechanical bdiaviors 
are typically represented as static nonlinear functions 
and lags or delays. The effect of malfunctions, 
introduced by the user through either the hardware or 
the software interface are also modeled. 

43. Flexible Modding Environment 

An important system requirement is the ability to 
change individual model elements rapidly between 
experiments. This provides the users with the capability 
of using varying levels of component model complexity 
to debug an undestrabte behavior in a system. The 
prc^lem area can be isolated first by choosing simple 
subsystem models and complex models can be used 
subsequently to perform root cause analysis of the 
problem. An user frierully modeling environment based 
on die SIMULINK* litmuy ccmcept has been developed 
to support reusability and flexibility [6]. The use of diis 
envinmment has significantly reduced the time to 
reconfigure models for various ap;dications. 
Additionaly, using a library source to implement a 
model that is used multiple times leads to ease of 
maintenance of the model architecture. 

5. Signal Interfadng and Conditioning 

The identification and implementation of the interface 
between the computing platform and PCM is extremely 
important and very time consuming. Issues related to 
Signal Transformations, Physical Signal Interfadng and 
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siimilationd'I/OHaidwaTc l^ult Conditions have to be 
sorted out An tihdepd) knowledge of the PCM circuitry 
and capabilities of the computational platfonn is 
necessary to address these issues. 

5.1. lYansf ormatlon Of Sfgnals 

An HIL environment requires signals from the 
computational platform to be interfaced to the hardware 
in the loop. Hence, signal transformations from the 
physical (electrical) domain to eogirteering units are 
required. As an example, engine fuel injector 
commands are electrical pulses to a sirfcnoid, but result 
in a fuel mass flow rate in the modd. Oenerally, the 
hardware interface signal behavior can be generated in 
one of several ways: 

1. Simulation output on the computing platform 

2. Output of an input-output signal pr o cess o r card 
3* Output die custom signal conditiomng boxes 
4. Ou^ of a custcMn hardware circuitry. 

Dunr^ die desigp (rfiase, one must d ecide on the proper 
partitioning of signal processing into available soltwaare 
and hardware. This results in a trade^fT between 
system complexity, computatioaal burden aiKi 
maintainability. By moving functionality from the 
models to the hardware interfece; the computational 
burden is decreased. This will free up computational 
resources to meet the real-time target However, the 
hardware interface may be c o me more co m plex and 
may require additioiml resources to matrrtntn it In the 
case of the fuel injector example, the primary task b to 
measure the duration of pulses commanded by the PCM 
v/hea the injectors are open. This task is completed in 
icvcial steps. The duration must be m e a sur ed with 
reference to the crankshaft angular pos it i on . There may 
also be an arbitrary number of ad^tional pulses to be 
measured widun a finite angular position of the engine 
(eg. 720 degrees of crank revohttion). All of dxese 
pulses mu^ be summed to r e piescn t a total fuel flow 
commanded by die PCM into individual cyKnders of 
die engine. To imi^eroent the primary task, a designer 
must choose to eidier let die computatwnal platform 
measure die pulses and gjenerate the rate of fuel flow 
into the engtoe cylinders^ or the hardware may be 
intelligcndy designed to measure the fuel flow and 
provide this as a scaled enginecrii^ unit value to the 
computational (datfionn. 

Another way to reserve the signal transformation issue 
is to have each of several processors tn the 
computational platform dcdtratcd to specific tasks. The 
core plant ir>odcl could be executed in a set of dedicated 
pr oce sso r s while the VO functionality couU be 
partitioned anumg several other processors. 


S.2. Physical Signal Inrerfftring 

The current state of the art in automodve powertrain 
control techrx>logy demands that PCMs interface widi a 
wide range of sensors and actuators. It is common to 
see a PCM widi 100 to 160 I/O pins and die HIL 
system must provide valid interface for each of diese 
pins. 

Powertrain controllers typically contain many types of 
output circuits depending on the automotive 
application. These include low side and hig;h side 
driven lumps, solenoids, and motors. There are also 
requirements for current controlled devices such as 
current controlled solenoids and high current - bigfi 
pressure solenoids. Controller inputs are differential 
variable rehictance sensors CVRSX switch inputs pulled 
up or down widun the controller. Hall eftet signals, 
and analog voltages from pressure and temperature 
sensors. The foUowing points are important when 
designing the HIL interfaces to these types of agnals: 

1. Some solenoid or current controlled driver circuits 
require feedback. For example, some drivers 
require a load inductance because they use 
switching circuits to control die current In odter 
cases, the flyback voltage from an inductive * 
actuator may be used to perf c»m diagnostics on the 
actuator. These special cases must be 
Bcconunodated by tht HIL S3rstem to prevent 
unintentional fault conditions from bdng detected. 

2. In many cases, current sensor technology provides 
simple analog voltage outputs for temperatures and 
pressures. In most cases, these signals may be 
emulated by using digital to analog (DAQ drivers 
in die HIL system. 

3. Where possible, the HIL system should utilize 
some farm of arbitrary waveform generation for 
VRS signals. This will allow users to simulate 
frmlt conditions for these signals. 

4. The interfadqg reqmrements of the driver circuitry 
widiin the PCM needs to be understood. In maiiy 
cases, output loads can be simulated with simple 
resistive loads as k)ng as the normal operating 
currents are preserved for the driver circuits. 

5. Key elements in the simulntrd load circuitry should 
be easy to modify. Sockets for resistive loads, 
separation of solerKMds or inductors into functional 
^packs' (e.g. simulated fuel injector inductors) that 
can be swapped arc two examples of how this will 
be accomplished. This will ensure that the HIL 
system can accommodate as many corurolter 
applications as possible. 
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To illustrate some of the ptunts described above, an 
imptemcma tioo of a simple reastive low side driven 
actoator is shown in Figure 2, In this case, the fault 
simulation block (see Section 5.3)» voltage level 
conversion, and noise immunity may reside in one 
system enclosure. The load, Rload, nuy reside in a 
separate load simulation enclosure with other simulated 
actuators, and the HIL system I/O hardware may be 
anodier enclosure which utilizes commercially 
available hardware (e.g. dmer/countcr capture ctrcuits, 
A/D circuits, DAC circuits, arbitrary waveform 
generators, etc.). 

SJL Sgnal Fault Simulatioo 

Automotive powertrain controllers utilize many 
intelligent integrated circuits for driving actuators and 
monitojing sensor outputs* This intdligence is 
necessary to accomplish self diagrxisis of feull 
conditions. In many cases, these diagnostics must be 
exe cut ed during nonnal operation of the PCM software. 
PCM software verification requires that the software be 
tested under nonnal aixl abnormal modes. Since the 
abnormal modes of c^teraticNi are tested under control, 
Che HIL system must have die ability to fofce fault 
conditions for api^opriate controller signals under 
automatic control. Typical fault conditions encountered 
in automotive environments are listed below: 

1. Short to ground - A controller signal has been short 
circuited to ground. 

2. Shon to battery ventage - A controller signal has a 
low resistance path to vehicle battery voltage. 

3. Open circuit - A controller signal has no path to 
ground. 

4. Shorted load - A controller actuator has been 
shorted to ground (the difference between this and 
a shtnt to ground is whether an actuator is driven 
from the high side or low side). 

In Figure 2, die I^t Sinmlatton block shows a method 
of implemendng fauh generation in a HIL ^stem. In 
this case, fudt nmolation is the last layer of hardware 
interface to the PCM signal. The fiuih amulation is 
accomplished tfnough a series of relays which may be 
ccmtrolled by die HIL simulator, tbese rel^ will 
ahcmately switch d»e PCM signal to either of the fault 
conditions or complete the signal path to the HIL 
simulator. 

Conchisloiis 

The task of putdng togedier a flexible HIL system for 
verification of production PCM performance is 
significam. In this paper, we have addressed two 
important HIL system aspects related to the real-time 
models and the hardware signal interface. Based on our 
experience, diese two issues retjuire a great deal of 


attention in the eariy stages of development and are 
critical to the success of HIL based product 
vcrificatioa Implementing the real-time model 
inlrasaucture involves structure tdendfication, 
parametrization and vaitdatioa The model structure has 
been described here. Parametrization aitd validation 
procedures are resource intensive and require extensive 
powertrain data. This will be die subject of a future 
publication. Hardware agnal interfacing and 
conditioning is a very OHnplex and time consuming 
activity. Having a good signal interface design and 
implementation will result in a well controlled system 
test Thb paper has identified several critical factors 
neetted to achieve a robust signal interface to the PCM 
Further details on the HIL system along widi the results 
of HIL based testing will be reported in a separate 
naner. 
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